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IMAP "SImportant" Keyword and "\Important" Special-Use Attribute 

Abstract 

RFC 6154 created an IMAP special-use LIST extension and defined an 

initial set of attributes. This document defines a new attribute, 

"\Important", and establishes a new IANA registry for IMAP folder 

attributes, which include the attributes defined in RFCs 5258, 3501, 

and 6154. This document also defines a new IMAP keyword, 

"SImportant", and registers it in the registry defined in RFC 5788. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
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1. Introduction 

The Internet Message Access Protocol (IMAP) specification [RFC3501] 
defines the use of message keywords, and an "IMAP Keywords" registry 
is created in [RFC5788]. [RFC6154] defines an extension to the IMAP 
LIST command for special-use mailboxes. The extension allows servers 


to provide extra information (attributes) about the purpose of a 
mailbox and defines an initial set of special-use attributes. 


This document does the following: 


o defines a new message keyword, "SImportant", to apply to messages 


that are considered important for the user by some externally 
defined criteria; 


o registers the "SImportant" keyword in the "IMAP Keywords" 
registry; 


o defines a new special-use attribute, "\Important", to designate a 
mailbox that will hold messages that are considered important for 


the user by some externally defined criteria; and 
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o creates a registry for IMAP mailbox attributes and registers the 
new attribute and those defined in [RFC5258], [RFC3501], and 


[RFC6154]. 
1.1. Conventions Used in This Document 
In the examples used in this document, "C:" indicates lines sent by a 
client that is connected to a server, and "S:" indicates lines sent 


by the server to the client. 
2. Definition of the "SImportant" Message Keyword 


The "SImportant" keyword is a signal that a message is likely 
important to the user. The keyword is generally expected to be set 
automatically by the system based on available signals (such as who 
the message is from, who else the message is addressed to, evaluation 


of the subject or content, or other heuristics). While the keyword 
also can be set by the user, that is not expected to be the primary 
usage. 


This is distinct from the "\Flagged" system flag in two ways: 


1. "SImportant" carries a meaning of general importance, as opposed 
to follow-up or urgency. It is meant to be used for a form of 
triage, with "\Flagged" remaining as a designation of special 
attention, need for follow-up, or time sensitivity. In 
particular, the sense of "SImportant" is that other messages that 
are "like this one" according to some server-applied heuristics 
will also be considered "SImportant". 


2. The setting of "SImportant" is expected to be based at least 
partly on heuristics (generally set automatically by the server), 
whereas "\Flagged" is only intended to be set by the user with 
some sort of "flag this message" or "put a star on this message" 
interface. 


3. Definition of the ’Important’ Mailbox Attribute 


The "\Important" mailbox attribute is a signal that the mailbox 
contains messages that are likely important to the user. In an 
implementation that also supports the "SImportant" keyword, this 
special use is likely to represent a virtual mailbox collecting 
messages (from other mailboxes) that are marked with the "SImportant" 
keyword. In other implementations, the system might automatically 
put messages there based on the same sorts of heuristics that are 
noted for the "SImportant" keyword (see Section 2). The distinctions 
between "\Important" and "\Flagged" for mailboxes are similar to 
those between "SImportant" and "\Flagged" for messages. 
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3.1. Formal Syntax 


The following syntax specification adds to the one in Section 6 of 
[RFC6154] using Augmented Backus-Naur Form (ABNF) as described in 
[RFC5234]. Be sure to see the ABNF notes at the beginning of 
Section 9 of [RFC3501]. 


use-attr =/ "\Important" 


3.2. Examples 
3.2.1. Example of a LIST Response 


In the following example, the mailbox called "Important Messages" is 
the one designated with the "\Important" attribute. 


tL GEST Oise 

* LIST (\HasNoChildren \Important) "/" "Important Messages" 
* LIST (\HasNoChildren) "/" "Imported Wine" 

tl OK Success 


nNNnNnWNA 


3.2.2. Examples of Creating a New Mailbox Using "\Important" 


In the following example, the mailbox called "Important Messages" is 
created with the "\Important" attribute on a server that advertises 
the "CREATE-SPECIAL-USE" capability string. 


C: tl CREATE "Important Messages" (USE (\Important) ) 
S: t1 OK Mailbox created 


The following example is similar to the previous one, but the server 
is not able to assign the "\Important" attribute to the new mailbox. 


C: tl CREATE "Important Messages" (USE (\Important) ) 
S: t1 NO [USEATTR] An \Important mailbox already exists 


The following example is similar to the previous one, but the server 
does not support this extension. 


C: tl CREATE "Important Messages" (USE (\Important) ) 
S: t1 NO [USEATTR] Mailbox not created; unsupported use \Important 


In both of the failure-mode examples, the "USEATTR" response code 
lets the client know that the problem is in the "USE" parameters. 
Note that the same response code is given in both cases, and the 
human-readable text is the only way to tell the difference. That 
text is not parsable by the client (it can only be logged and/or 
reported to the user). 
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4. Implementation Notes 


This section is non-normative and is intended to describe the 
intended (and current as of this publication) usage of "SImportant" 
in contrast with "\Flagged" on a message. 


On the server: 


o "\Flagged" is set or cleared in response to an explicit command 
from the client. 


o "SImportant" is set via a heuristic process performed by the 
server and usually involves analysis of header fields, what 
mailbox the message is filed in, perhaps message content, 
attachments, and such. It may then be set or cleared in response 
to an explicit command from the client, and the server may use 
that to adjust the heuristics in the future. It’s also possible 
that the server will re-evaluate this and make a message 
"SImportant" later if the user accesses the message frequently, 
for example. 


On the client: 


o Typically, an icon such as a flag or a star (or an indication, 
such as red or bold text) is associated with "\Flagged", and the 
UI provides a way for the user to turn that icon or indication on 
or off. Manipulation of this results in a command to the server. 


o Typically, a lesser indication is used for "SImportant". The 
client might or might not provide the user with a way to 
manipulate it. If it does, manipulation results in a command to 


the server. 
5. Security Considerations 


The security considerations in Section 7 of [RFC6154] apply equally 
to this extension, in particular, "Conveying special-use information 
to a client exposes a small bit of extra information that could be of 
value to an attacker." Moreover, identifying important messages or a 
place where important messages are kept could give an attacker a 
strategic starting point. If the algorithm by which messages are 
determined to be important is well known, still more information is 
exposed -- perhaps, for example, there is an implication that the 
senders of these messages are particularly significant to the mailbox 
owner, and perhaps that is information that should not be made 
public. 
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As noted in RFC 6154, it is wise to protect the IMAP channel from 
passive eavesdropping and to defend against unauthorized discernment 
of the identity of a user’s "\Important" mailbox or of a user’s 
"SImportant" messages. See Section 11 of [RFC3501] for security 
considerations about using the IMAP STARTTLS command to protect the 
IMAP channel. 


6. IANA Considerations 


IANA has completed three actions, which are specified in the sections 


below: 

1. registration of the "S$Important" keyword; 

2. creation of a new "IMAP Mailbox Name Attributes" registry; and 
3. registration of initial entries in the "IMAP Mailbox Name 


Attributes" registry. 
6.1. Registration of the "SImportant" Keyword 


IANA has registered the "$Important" keyword in the "IMAP Keywords" 
registry, as follows, using the template in [RFC5788]. 


IMAP keyword name: $Important 


Purpose (description): The "SImportant" keyword is a signal that a 
message is likely important to the user. 


Private or Shared on a server: PRIVATE 


Is it an advisory keyword or may it cause an automatic action: 
Advisory (but see the reference for details). 


When/by whom the keyword is set/cleared: The keyword can be set by 
the user, or automatically by the system based on available 
signals (such as who the message is from, who else the message 
is addressed to, evaluation of the subject or content, or other 
heuristics). 


Related keywords: None (see the reference for the related mailbox 
name attribute). 


Related IMAP capabilities: None. 
Security considerations: See Section 5 of RFC 8457. 


Published specification: RFC 8457 
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Person & email address to contact for further information: 
IETF Applications and Real-Time Area <art@ietf.org> 
Intended usage: COMMON 
Owner/Change controller: IESG 
Note: None. 
6.2. Creation of the IMAP Mailbox Name Attributes Registry 


IANA has created a new registry in the group "Internet Message Access 


Protocol (IMAP)". It is called "IMAP Mailbox Name Attributes", and 
it has two references: "RFC 3501, Section 7.2.2", and "RFC 8457, 
Section 6". This registry will be shared with the JSON Meta 


Application Protocol (JMAP) for Mail [JMAP-MAIL]. 
The registry entries contain the following fields: 


Attribute Name 
Description 
Reference 
Usage Notes 


BWDN EF 


IANA keeps this list in alphabetical order by Attribute Name, which 
is registered without the initial backslash ("\"). The names are 
generally registered with initial capital letters but are treated as 
case-insensitive US-ASCII strings. 


The "Usage Notes" field is free-form US-ASCII text that will normally 
be empty (and is empty if it’s not specified in the registration 
request). It is intended to hold things such as "not used by JMAP" 
and "JMAP only". The field is for human use, and there is no need 
for a registry of strings that may appear here. 


The registration policy for the new registry is listed as "IETF 
Review" or "Expert Review" [RFC8126], and new registrations will be 
accepted in one of two ways: 


1. For registrations requested in an IETF consensus document, the 
registration policy will be IETF Review, and the request will be 
made in the IANA Considerations section of the document, which 
gives the requested values for each of the fields. 


2. For other registrations, the policy will be Expert Review policy 
(see Section 6.2.1), and the request will be made by sending 
email to IANA asking for a new IMAP Mailbox Name Attribute and 
giving the requested values for each of the fields. While a 


Leiba Standards Track [Page 7] 


RFC 


8457 IMAP "Important" Keyword and Attribute September 2018 


formal specification is not required, the reference document 
should provide a description of the proposed attribute sufficient 
for building interoperable implementations. An Informational RFC 
(submitted, for example, through the IETF or Independent stream) 
is a fine way to publish a reference document (see also 

Section 6.2.1). 


.1. Instructions to the Designated Expert 


The expert reviewer, who will be designated by the IESG, is expected 
to provide only a general review of the requested registration, 
checking that the reference and description are adequate for 
understanding the intent of the registered attribute. Efforts should 
also be made to generalize the intent of an attribute so that 
multiple implementations with the same requirements may reuse 
existing attributes. Except for this check, this is intended to be 
very close to a first come first served policy, and the expert should 
not block serious registration requests with a reasonable reference. 
The reference may be to any form of documentation, including a web 
page, but consideration should be given to providing one that is 
expected to be long-lived and stable. 
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6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 


The registry initially contains these entries: 


+ + + + 
| Attribute | Description | Reference | 
| Name | | | 
+ + + + 
| All | All messages | [RFC6154] | 
toss 55555 a sn pors antoi + 
| Archive | Archived messages | [RFC6154] | 
toss asa fess eae eee aa oS op ae oe to--- 7-7-7 + 
| Drafts | Messages that are working drafts | [RFC6154] | 
stan Fn to-- 7-77 -- + 
| Flagged | Messages with the \Flagged flag | [RFC6154] | 
see Fn to--- 7777-7 + 
| HasChildren | Has accessible child mailboxes | [RFC5258] | * 
EE Sm aan E Sayama + 
| HasNoChildren | Has no accessible child mailboxes | [RFC5258] | * 
Sige ame ae mina ae ee aS a ae a ee ee ee ees #eSssSsSSSss + 
| Important | Messages deemed important to user | RFC 8457 | 
toa sss 555 pee ee ee a ee ae ae ee ee HSS SRSsRe SF + 
| Junk | Messages identified as Spam/Junk | [RFC6154] | 
to- 555555 Hosa SoSH SS RSS Se SS Se ee eS teSsacseaeS + 
| Marked | Server has marked the mailbox as | [RFC3501] | * 
| | "interesting" | | 
RA se oma ac a to--- 7-7-7 + 
| NoInferiors | No hierarchy under this name | [RFC3501] | * 
sean hee Seay a em ae Se eo HSBHRSSHeSeS + 
| NonExistent | The mailbox name doesn’t actually | [RFC5258] | * 
| | exist | | 
Sian E aie E Pe SS ee ee ae Fascia Aes a asad + 
| Noselect | The mailbox is not selectable | [RFC3501] | * 
EEA EENT EERSTE IRE PEARS + 
| Remote | The mailbox exists on a remote | [RFC5258] | * 
| | server | | 
EOE En fsan eah e a þanna + 
| Sent | Sent mail | [RFC6154] | 
tos a See SSeS too SS SS a eS paien + 
| Subscribed | The mailbox is subscribed to | [RFC5258] | 
AE ae TN E a Poean nE + 
| Trash | Messages the user has discarded | [RFC6154] | 
$oSS SSS SSS ssa Sa aa a aaa tease SS aS + 
| Unmarked | No new messages since last select | [RFC3501] | * 
+ + + + 


The rows marked with "*" at the end have their Usage Notes field set 
to "not used by JMAP". 
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